Is there a specific reason you specified a void return type for foo()? Do abstract methods always need a strictly defined return type?

If not, might I recommend a different return type for clarity?

(Edited because I missed a part in the OP description)

Fantastic start on this feature. Thank you!

One comment: please use implements over uses, as per the original proposal.

I'm not sure your reasoning lines up with your conclusion there, but I can't say I have much of a preference, what with it being a strictly cosmetic affair.

This system seems very similar to the abstract keyword, which has already been suggested.. what makes this approach better than abstract classes?
I already use a lot of base classes with empty functions that are then overridden in my game currently. Will this improve the workflow comparatively?

Abstract classes are still beholden to the class hierarchy: No class can inherit from two classes at a time.

There is some value in having both of these, I suppose, but traits are far more powerful.

This system seems very similar to the abstract keyword, which has already been suggested.. what makes this approach better than abstract classes?

See:

• Add a keyword for abstract classes in GDScript #67777
• Implement abstract methods in GDScript #82987

Also, as DaloLorn said, these are independent features that can coexist together. Traits offer capabilities that classic inheritance cannot provide.

This looks great, will traits be able to constrain typed collections (ie. Array[Punchable], Dictionary[String, Kickable]) ?

Amazing that somebody cared to make this,but since the original proposal is shut down,here is some feedback

1. use impl instead of uses,this makes more sense and also is short too
2. don't have a seperate file extension for traits,have .gd files be able to support different object types
3. no trait_name, name it instead type_name
4. traits should only have functions (abstract and virtual),no other stuff

4. traits should only have functions (abstract and virtual),no other stuff

Considering work has already been made for signals, we should get to keep them too. (unless massive performance issues appear)

I am a bit concerned on the performance of this in general, but that would be something that can be solved over time. I am really, really ecstatic about this.

I agree. There's no reason to exclude signals from traits if the work has been done.

As various others have suggested to use impl instead of implements, I wanted to make a case against impl. Take this example:

class_name SomeClass
extends BaseClass
impl TraitA

• impl is inconsistently abbreviated next to the written-out extends and class_name keywords that will almost always be just above or below it.
• for non-native English speakers, impl is harder to understand at first glance, and un-google-able for translation.
• If contributors want Godot to be beginner friendly, writing out implements is the more friendly option here, because it requires less knowledge of the programming language and associated jargon.
• as rightfully mentioned on mastodon in response to me yapping about engine UX, impl could imply "implies", "impels", "implant", "implode".

The 6 characters impl saves over implements is not worth the confusion and inconsistency. Instead, perhaps you would agree with me that this is much more readable and consistent:

class_name SomeClass
extends BaseClass
implements TraitA

impl is inconsistently abbreviated next to the written-out extends and class_name keywords that will almost always be just above or below it.

what would you abbreviate extends and class_name to? only answers i can think of is for class_name, which could be changed to use the script name, and extends could just be extend

for non-native English speakers, impl is harder to understand at first glance, and un-google-able for translation.

Pretty sure non-native speakers are able to understand abbreviations, by your logic int and bool should be Integer and Boolean, this doesn't include all the abbreviated types that exist already

If contributors want Godot to be beginner friendly, writing out implements is the more friendly option here, because it requires less knowledge of the programming language and associated jargon.

traits aren't exactly beginner stuff, when someone starts with a language they learn they might learn traits ,but for gamedev you don't learn certain stuff until you get the basics/become a casual programmer , when i was a unity developer, i didn't learn about interfaces (which are extremely similar to traits) until i had advanced enough and realised i need some other solution to inheritance

as rightfully mentioned on mastodon in response to me yapping about engine UX, impl could imply "implies", "impels", "implant", "implode".

this makes no sense? let's take a look at some example code:

class_name Door
extends AnimatableBody3D
impl Interactable

what would "implies" mean in a progammer context?, "impels" isn't even abbreviated correctly, "implant"? seriously?, "implode" would be a function for gameplay

The 6 characters impl saves over implements is not worth the confusion and inconsistency. Instead, perhaps you would agree with me that this is much more readable and consistent

previous points still matter, also rust uses the impl keyword, and i am pretty sure it popularized the concept of traits and yet still 0 complains from it

Is using a separate file extension necessary? And if not, would it be better to stick to .gd? From a UX perspective it seems a lot simpler and easier not to.

Is using a separate file extension necessary? And if not, would it be better to stick to .gd? From a UX perspective it seems a lot simpler and easier not to.

Extensions can be useful for quick search, filter, etc., without the need to check the content of the file nor adding extra prefix/suffix to file names (so it's better in UX terms), also can help other tools like the filesystem to implement custom icons.

Put me down as another vote in favor of "implements", for what it's worth. I'm indifferent on "implements" versus "uses", but I'm not nearly so indifferent on "impl" versus "implements": The majority of Adriaan's concerns have not been addressed to my satisfaction.

As various others have suggested to use impl instead of implements, I wanted to make a case against impl. Take this example:

class_name SomeClass
extends BaseClass
impl TraitA

• impl is inconsistently abbreviated next to the written-out extends and class_name keywords that will almost always be just above or below it.
• for non-native English speakers, impl is harder to understand at first glance, and un-google-able for translation.
• If contributors want Godot to be beginner friendly, writing out implements is the more friendly option here, because it requires less knowledge of the programming language and associated jargon.
• as rightfully mentioned on mastodon in response to me yapping about engine UX, impl could imply "implies", "impels", "implant", "implode".

The 6 characters impl saves over implements is not worth the confusion and inconsistency. Instead, perhaps you would agree with me that this is much more readable and consistent:

class_name SomeClass
extends BaseClass
implements TraitA

I think uses is fine.

I agree on "impl" been a very confusing keyword.

To resolve the class reference error: Compile godot, then run ./bin/godot<TAB> --doctool, then push the result.

While working on the documentation, I found behavior with static variables in traits that seems like it might not make sense?

Nice catch, that was a bug. It is now fix and have write a test for it.
Here example how it should work

trait SomeTrait:
	static var some_static_var = 0
	static var other_static_var = 0
	static var third_static_var = 0
	static func some_static_func():
		print("some static func")
	static func other_static_func():
		print("other static func")
	static func third_static_func():
		print("third static func")

class SomeClass:
	uses SomeTrait
	# Overridden static variable
	var other_static_var = 1 # using 'static' keyword is optional
	static var third_static_var = 1
	# Overridden static function
	func other_static_func(): # using 'static' keyword is optional
		print("overridden other static func")
	static func third_static_func():
		print("overridden third static func")

func _ready():
	print(SomeClass.some_static_var)
	print(SomeClass.other_static_var)
	print(SomeClass.third_static_var)
	SomeClass.some_static_func()
	SomeClass.other_static_func()
	SomeClass.third_static_func()
	print("ok")

If static function/variable is declared in a trait, when redeclared/overridden in class should using 'static' keyword is optional ? (currently it is)

because some_var is static to the trait itself, so you would have to do

print(SomeTrait.some_var)

This is not correct traits are not object and should not be instanced or called, I will look for way to better communicate this to prevent misuse.

If static function/variable is declared in a trait, when redeclared/overridden in class should using 'static' keyword is optional ? (currently it is)

Personally, I strongly feel that the static keyword should not be optional. If the user wants to redefine its value for a class that uses a trait, then I think one of these should work:

class MyClass:
    uses MyTrait
    static var some_static_var  = 2  # inherited from MyTrait
    # OR
    some_static_var = 2  # also inherited from MyTrait

The static var count = ... makes it clear to whoever's reading this class file that count is a static variable, whereas if it was simply var count = ... they would naturally assume it's an instance variable and be confused when they're not allowed to do instance.count.

Simply having count = ... works with the idea that we've already declared the variable itself in the trait, and now we're just modifying the value here, like how var local_value = ... initializes the variable and local_value = ... changes the value. I could see others being opposed to this syntax being up at the class member definition level, though, and can understand their reasoning, so overall I think just requiring the static keyword makes the most sense.

I pulled the recent changes to verify the static variable behavior, and while it looks like it's closer to what is expected (at least to me), I think I may have found an inconsistency with it. I used this code:

extends Node2D

trait HasStatic:
    static var static_var = 3

class UsingClass:
    uses HasStatic
    
class DifferentUsingClass:
    uses HasStatic

func _ready():
    UsingClass.static_var = 2
    print("HasStatic's value: ", HasStatic.static_var)
    print("UsingClass's value: ", UsingClass.static_var)
    print("DifferentUsingClass's value: ", DifferentUsingClass.static_var)

This prints out:

HasStatic's value: <null>
UsingClass's value: 2
DifferentUsingClass's value: <null>

I would expect it to print out:

HasStatic's value: 3
UsingClass's value: 2
DifferentUsingClass's value: 3

Does this sound like unexpected behavior, or am I missing something with how static variables are expected to work in traits?

I pulled the recent changes to verify the static variable behavior, and while it looks like it's closer to what is expected (at least to me), I think I may have found an inconsistency with it.

Fixed and now has a test.

 print("HasStatic's value: ", HasStatic.static_var)

This is illegal, now you get an error, traits should be considered as templates and can not be objects ,hence, not directly access to its member, calling or instancing.

class SomeClass:
	uses SomeTrait
	# Overridden static variable
	var other_static_var = 1 # using 'static' keyword is optional
	static var third_static_var = 1

I decided to go with this remaining optional, however, you get a warning. same applies on overriding variables that use @onready

This simple code fails:

trait TestTrait extends Node:
	pass

func test_func(node: Node):
	if node is TestTrait:
		pass

Expression is of type "Node" so it can't be of type "TestTrait".

This works:

func test_func(node: Node):
	var traiter := node as TestTrait
	if traiter:
		pass

I can double-check on my end, but I thought the syntax for inner traits would be:

trait TestTrait:
    extends Node

?

Edit: Regardless of which syntax is correct (or if both are), my variation gets the same error:

trait TestTrait2:
    extends Node

func test_func(node: Node):
    if node is TestTrait2:
        pass

Expression is of type "Node" so it can't be of type "TestTrait2".

Some editor bugs:

• Overriden methods from trait don't show inherited icon.
  
  (attack() is from a trait)
  You also can't Ctrl+Click it to go to base implementation.

• Saving a trait used in a built-in script, makes this script "unsaved":

EDIT:
Cyclic dependencies have problems. I have a global class with enum, and it refers to a trait and the trait uses the enum as a type for one of variables.

In a script that tries to use this trait I get this error:

Parser bug (please report): Could not find external parser for class "Player". (Trying to resolve datatype of class member)

In another project I had error that variables were not found when trying to refer to variables from trait, not sure how to reproduce it.

The bugged scripts:
Traits.zip
The script with error:

extends Node
uses PlayerWeapon

func _ready() -> void:
	attack_type = 5 # If the script manages to parse, this will result in runtime error.

EDIT2:
I tried to workaround the above by moving the enum to trait, but trait enumes can't be used without class. That's rather unexpected tbh.

Edit: Regardless of which syntax is correct (or if both are), my variation gets the same error:

In your variation the trait extends RefCounted (default base class), so the error is correct.

EDIT:
Or at least I assumed that based on how classes work currently.
Maybe it's worth it to make the default Object? Classes using traits need their own extend anyway, so this would make traits more universal.

since the og proposal is locked, i am forced to state my opinion here, i believe traits shouldn't have variables, i can go overkill and say signals don't deserve to be in traits, but i feel (not know) there may be cases where signals are needed, but variables? pretty sure only C++ does this and C++ is known for tons of bad stuff, if variables are desperately needed, once can use a function getter and setter and otherwise should be in classes, for static stuff, i am not really sure how static stuff would even work, static stuff is related to the type, and traits are types, and we would need reflection/metaprogramming, to better explain

trait Interactable:
    pass

func f():
    if i is Interactable:
        i.interact()
    if typeof(i).traits.has(Interactable):
       typeof(i).static_interact()

get it now? if a type requires a static method, chances are you would put it in the class

quick edit: the prev code is a mock code of what is gdscript needs to have to use static functions correctly and is meant to showcase how useless and troublesome it will be

signals are helpful in interfaces/traits since you can do something like:

trait_name Destroyable:

signal destroyed(self: Destroyable)

@Dynamic-Pistol you can create a discussion to talk about this

I don't want to extend the off topic but I want to add that the implications of variables in traits are huge and can add a lot of flexibility, just think on how these can be used in resources and other data types, to extend and to patch them